Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autotest: bad fix for failing Sub test #12886

Closed
wants to merge 1 commit into from

Conversation

peterbarker
Copy link
Contributor

There is something significantly wrong with Sub's manual input at the
moment.

Stepping the input up to 1525 yields sensible results. 1526 is a
break-value - spin goes up dramatically.

The test currently flaps as it is random as to whether any given VFR_HUD
packet will be at the expected heading - this thing spins very, very
fast.

@jaxxzer - we need to apply this very, very bad fix, or perhaps disable the test; CI randomly fails for people ATM.

It's a pretty serious regression that the test seems to have caught, however.

There is something significantly wrong with Sub's manual input at the
moment.

Stepping the input up to 1525 yields sensible results.  1526 is a
break-value - spin goes up dramatically.

The test currently flaps as it is random as to whether any given VFR_HUD
packet will be at the expected heading - this thing spins very, very
fast.
@jaxxzer
Copy link
Member

jaxxzer commented Nov 26, 2019

It looks like the vehicle is not actually spinning very fast. Looking at logs, it is turning ~2 rad per second.

It appears that the -s option is not having an effect on the simulation speed. We noticed that the SIM_SPEEDUP parameter was not affected by the -s option. After re-configuring the parameter, the simulation speed works as expected.

I think this is the problem, but I'm not sure where to look from here.

@Williangalvani
Copy link
Contributor

Williangalvani commented Nov 27, 2019

Ok, @jaxxzer response was based on some tests I ran earlier today in my laptop. SITL was behaving poorly but right now I think that is not really the issue.

Looking further into the log I found this:
Screenshot from 2019-11-27 01-37-59

both graphs for Lat and for Yaw are jumping between the expected curve and a flat one.
Is it possible that we have two instances running simultaneously?

Edit: Nevermind, I now think the graphs are doubled because I use time from boot for the x axis, and that resets with the reboot, making my plot "restart"

@peterbarker
Copy link
Contributor Author

2 radians per second is pretty darn fast for a sub :-)

360 degrees/second, VFR_HUD is at 4Hz, meaning we'll see the heading every 90 degrees or so :-)

image

That's me stepping up the RC input in 1pwm increments. As soon as it gets out of the DZ it starts to spin at 50 degrees/second. Is that expected?

Did we sort out what was going on with speedup?

@peterbarker
Copy link
Contributor Author

Closed in favour of the referenced PR.

@peterbarker peterbarker deleted the pr/sub-fix branch November 29, 2019 00:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants